[WIP] Add tests and Travis CI config #784
Conversation
|
Thanks for digging into this.
What is the rational here, if I may ask? Some issue with Perl? |
|
Just work in progress. I can add Perl to the Docker image since pod2man is
needed to generate man files. I am traveling now but I will fix it ASAP.
El 8 dic. 2017 10:53, "Remy Marquis" <[email protected]> escribió:
… Thanks for digging into this.
follow steps to install pacaur shown in its PKGBUILD except man
generation/install.
What is the rational here, if I may ask?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#784 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIFd-kDKm331Pv6LN1TCMgGY4t4Kjctmks5s-QcsgaJpZM4Q5Ztv>
.
|
|
In that case, wouldn't be easier and more logical to use the pacaur PKGBUILD + I guess even hosting the PKGBUILD of the stable version would make sense. |
|
The problem here would be testing changes in non-master branches, PRs, etc.
We would need to generate/change PKGBUILDs during the test to point to the
commit. Definitely, it is feasible but not sure if offers any advantage.
In any case, I think it is a nice idea to test installation of pacaur and
pacaur-git in a clean environment. We can already do that in the Docker
image. However, I think this is a different kind of automated testing and
should be separated from the CI of the repo, or at least not triggered by
every change. We could test pacaur-git only in master branch changes and
pacaur in tagged releases.
El 8 dic. 2017 18:41, "Remy Marquis" <[email protected]> escribió:
… In that case, wouldn't be easier and more logical to use the pacaur
PKGBUILD + makpekg -sri directly instead of duplicating its content? This
way, we could ensure the official way of installing is also done on docker.
The (pacaur-git) PKGBUILD would obviously need to be stored in the git repo.
I guess even hosting the PKGBUILD of the stable version would make sense.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#784 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIFd-jeEyzUkkLIB9OZQg-IhmRzNDk2Uks5s-XS-gaJpZM4Q5Ztv>
.
|
Good point. In that case, here is another proposal: Move the PKGBUILDs content to a buildsystem ( |
ismaelgv
force-pushed
the
ci-tests
branch
2 times, most recently
from
d63e9d1 to
7cfa941
Compare
|
I have created a simple Makefile that works pretty well in combination with CI. I suppose you could use |
Yes, that is the idea. |
|
I've added DESTDIR and PREFIX to the Makefile. PREFIX is set to make install DESTDIR=$pkgdir PREFIX=/usrI've installed |
|
Reworked the Makefile, based on your work. Thanks! |
* Travis CI configuration * Add arch-pacaur Docker image. * Add basic package tests.
|
Even if you start from scratch you can use .travis.yml and Dockerfile of this PR. It will not do any harm to the final user to got some tests right now, independendently of future massive overhaul. I have removed Makefile conflict from this PR, and now there is only:
|
In this PR, there are several additions related to the test discussion in #708:
I've tested this workflow in my fork and it seems to work quite fine. Obviously, you need to activate Travis CI for this project.
Basically, we generate a local Docker image from
base/develcalledarch-pacaurusingtests/image/Dockerfile. This image contains allpacaurdependencies, includingcower. We usearch-pacaurimage to run two types of tests:tests/test_install.sh- must be run with sudo): follow steps to installpacaurshown in its PKGBUILD except man generation/install.tests/test_packages.sh): test system updating, package installation and removal.I've tried to develop this test workflow as flexible and extensible as possible. The idea is adding more test eventually.
Note 1: Docker image is generated before each test since it is using a Travis test matrix. Test matrix is used to run every test in parallel. It does not takes long to build Docker image anyways (~1 minute and 30 secs).
Note 2: These tests have been developed to be run in the Docker image, may cause unexpected results if they are ran in an actual system.